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ABSTRACT 

For  the  Communication  Systems  Network  Interoperability  (CSNI  )  project  two  different  protocols  were 
implemented  for  the  SATCOM  subnetworks.  The  United  Kingdom  developed  a  TDMA/Token  Ring  protocol  for 
SHF  SATCOM  subnetwork  and  the  United  States  developed  a  Reservation  Protocol  for  UHF  SATCOM  subnetwork. 
The  U.K.  provided  two  versions  of  their  protocol.  One  version  supports  a  multiple  member  subnetwork  and  is  used 
with  the  WESTLANT  DSCS  satellite.  Canada,  Shape  Technical  Centre  (STC),  U.K.  and  the  U.S.  formed  the 
members  of  this  subnetwork.  The  link  data  rate  for  this  subnetwork  is  56  kbps.  The  second  version  supports  a  point 
to  point  connection  and  is  used  with  the  NATO  IV  satellite.  There  are  three  SHF  point  to  point  links:  STC- 
Netherlands,  STC-Germany  and  U.K.-Germany.  All  the  point  to  point  links  support  a  link  data  rate  of  64  kbps. 

There  are  two  UHF  SATCOM  subnetworks.  Both  use  the  same  reservation  protocol.  One  subnetwork  uses 
the  FLTSAT7  satellite  and  consists  of  three  nodes:  Canada,  U.S.  at  NRaD  and  U.S.  at  NRL.  The  second  subnetwork 
uses  the  FLTSATl  or  8  satellite  and  consists  five  nodes:  Canada,  three  nodes  in  the  U.K.  and  the  U.S.  at  NRL.  The 
link  data  rate  for  both  subnetworks  is  9.6  kbps. 

All  the  designs  adhere  to  the  CSNI  SNAC  External  Interface  Specification  which  allows  any  CSNI 
subnetwork  to  attach  to  any  participating  CSNI  intermediate  system.  This  paper  discusses  the  protocols  and  how  the 
software  is  implemented.  A  discuss  of  the  over  the  air  test  results  is  also  provided. 

1.0  INTRODUCTION 

Two  SATCOM  subnetworks  were  developed  for  CSNI:  SHF  and  UHF.  Figures  1  and  2  show  the  topology 
of  the  two  subnetworks.  The  SHF  SATCOM  subnetwork  consists  of  one  4  member  subnetwork  and  three  point  to 
point  links.  The  subnetwork  uses  the  U.S.'s  Defense  Satellite  Communications  System  (DSCS)  Phase  HE  satellite 
located  at  53  degrees  west.  The  point  to  point  links  use  individual  64  kbps  channels  on  the  North  Atlantic  Treaty 
Organization  (NATO)  IV  satellite.  The  U.K.  developed  a  TDMA/token  ring  protocol  for  the  DSCS  subnetwork.  The 
protocol  was  modified  to  work  for  the  point  to  point  NATO  IV  links. 


Figure  1 .  SHF  SATCOM  Subnetwork 


Figure  2.  UHF  SATCOM  Subnetwork 
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The  UHF  SATCOM  subnetwork  actually  consists  of  two  subnetworks.  One  subnet  uses  the  U.S.’s 
FLTSAT7  satellite.  This  satellite  is  located  at  100  degrees  west  and  is  only  visible  to  nodes  in  North  America.  The 
second  subnetwork  uses  FLTSAT8  which  is  located  at  23  degrees  west  and  occasionally  FLTSATl  (15  degrees 
west).  These  two  satellites  are  visible  to  the  nodes  on  the  east  coast  of  North  America  and  Europe.  The  protocol 
used  on  both  UHF  subnets  is  a  reservation  protocol.  The  protocol  was  developed  by  the  U.S.  on  a  previous  program 
and  adapted  to  UHF  SATCOM. 


2.0  SHF  SATCOM 

2.1  Protocol  Description 

2.1.1  DSCS 

This  subnet  is  a  "broadcast"  network.  The  protocol  is  based  on  TDM  A,  but  with  the  slots  allocated  on  a 
"token  passing"  basis.  The  following  is  a  summary  of  the  protocol,  for  more  detail  see  refs.  [1]  and  [2].  The  protocol 
allows  a  number  of  stations  (maximum  64,  but  more  than  twenty  would  probably  be  impractical)  to  share  a  single 
1 12  kbps  satellite  channel  (the  user  date  rate  is  56  kbps),  by  time-division  multiplexing.  There  is  no  master  station, 
and  therefore  no  single  ground-based  point  of  vulnerability. 

The  protocol  is  based  on  a  frame  length  of  0.7  seconds,  this  is  divided  into  ten  individually  allocated  time 
slots.  The  tenth  slot  in  every  frame  cannot  be  owned  by  any  of  the  subnet  members,  it  is  designated  the  "empty  slot" 
and  is  used  by  nodes  wishing  to  join  the  subnet.  The  protocol  uses  a  system  of  tokens  to  share  the  available  slots 
among  the  stations.  There  is  one  token  for  each  slot  in  the  frame  which  is  available  for  data  transfer  (there  are  nine 
slots  available  for  data  transfer).  The  system  allows  stations  to  take  varying  proportions  of  the  bandwidth.  Each 
subnet  member  is  passed  token(s)  in  turn,  the  member  with  the  slot  token  transmits  in  that  slot  in  the  current  frame 
and  passes  the  slot  onto  the  next  member. 

Figure  3  shows  the  frame  and  slot  structure  used  by  the  DSCS  protocol  (with  n=10),  the  Data  part  of  the  slot 
is  420  bytes  long  and  contains  a  Subnetwork  Protocol  Data  Unit  (SnPDU),  Figure  4  shows  the  format  of  an  SnPDU. 


Each  slot  contains  a  SnPDU  .  Each  SnPDU  can  contain  one  or  more  NPDUs/NPDU  segments  (or  a  mix  of 
both  whole  NPDUs  and  segments).  All  correctly  received  Data  NPDUs/NPDU  segments  are  acknowledged.  The 
recipient  Subnetwork  Access  Control  (SNAC)  should  transmit  an  acknowledgment  to  the  originating  SNAC  in  the 
next  slot  available  to  him.  If  an  acknowledgment  is  not  received  by  the  station  who  transmitted  the  NPDU  within  N 
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seconds,  then  the  NPDU  is  retransmitted,  (retransmission  will  occur  R  times,  after  which  the  NPDU  will  be 
discarded  and  the  appropriate  action  taken). 


Token  Handling  Group  (six  bytes) 


Acknowledgement  Group  (variable  length) 


NPDU  Descriptor  Group  (variable  length) 


NPDU  Group  (variable  length) 


Figure  4.  Structure  of  SnPDU 


The  protocol  supports  the  CSNI  group  addressing  scheme  as  described  in  ref.  [3]. 

A  transmit  queuing  capability  is  maintained  by  the  SNAC.  The  data  sent  by  the  IS  is  queued  on  a  first- 
in/first-out  (FIFO)  basis  per  priority  level.  Data  is  selected  for  transmission  on  the  basis  of  highest  priority  first. 

Received  data  is  examined  and  routed  to  the  destination  IS.  Any  data  within  the  received  SnPDU  that  is  not 
directed  to  the  local  IS  is  discarded. 

The  DSCS  protocol  provides  the  functionality  required  to  reserve  fixed  rate  "channels"  at  2.4  kbps,  this  can 
be  used  to  support  the  CSNI  Real  Time  Voice  (RTV)  Protocol.  In  the  RTV  protocol  a  slot  is  reserved  for  a  voice  call 
and  the  slot  is  passed  between  the  two  "ends"  of  the  call  by  PTT_ON/PTT_OFF  signaling. 

The  channel  capacity  is  56  kbps,  after  taking  into  account  headers  and  guard  times  the  overall  data  capacity 
of  the  subnet  is  approximately  41.5  kbps.  The  DSCS  subnet  has  only  four  users  at  present,  therefore  each  user  has 
around  10  kbps  of  data  capacity. 

2.1.2  NATO 

The  protocol  for  this  subnet  is  based  on  the  DSCS  protocol.  The  following  is  a  summary  of  the  protocol,  for 
more  detail  please  see  refs.  [1]  and  [4].  The  basic  frame  length  (0.7  seconds)  and  slot  structure  (420  bytes)  of  the 
DSCS  protocol  has  be  retained,  but  each  PO  owns  all  the  slots  for  their  part  of  the  link,  (e.g.  UK  will  have  13 
slots/frame  to  pass  information  to  GE,  and  GE  will  have  13  slots/frame  to  pass  information  to  the  UK).  The  increase 
in  slots  over  the  DSCS  Protocol  is  due  to  the  higher  data  rate  of  the  NATO  IV  subnet.  The  user  data  rate  of  this 
subnet  will  be  64  kbps. 

Figure  3  shows  the  frame  and  slot  structure  used  by  the  DSCS  protocol  (with  n=13).  As  with  the  DSCS 
Protocol,  each  slot  contains  an  SnPDU  (Figure  4).  The  acknowledgment  procedure  differs  from  the  DSCS  Protocol 
in  that  the  recipient  station  does  not  have  to  wait  for  a  slot  to  be  handed  to  him  (he  owns  all  13  slots)  before  he  sends 
an  acknowledgment.  The  slot  structure  is  not  required  for  point-to-point  operation,  but  was  retained  for  simplicity  of 
implementation  (being  as  it  is  based  on  the  DSCS  protocol). 

The  utilization  of  the  slots  within  NATO  is  identical  to  that  for  DSCS  (described  in  2.1.1  above). 

The  NATO  protocol  provides  the  "channel"  reservation  required  the  support  the  CSNI  Real  Time  Voice 
(RTV)  Protocol.  In  the  NATO  subnetwork  a  slot  is  reserved  in  each  direction  for  a  voice  call,  the  NATO  protocol 
consisting  of  full  duplex  point-to-point  links. 

The  channel  capacity  is  64  kbps,  after  taking  into  account  headers  and  guard  times  the  overall  data  capacity 
of  the  subnet  is  approximately  53.6  kbps.  Because  this  subnet  consists  of  three  separate  full  duplex  links  each 
member  of  the  NATO  IV  subnet  has  the  53.6  kbps  capacity  per  link  available  for  him  alone  to  use. 
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2.2  Software  Implementation 

All  the  software  for  both  SHF  SATCOM  subnets  was  written  in  C  using  the  VxWorks  development 
environment.  The  code  was  implemented  to  run  on  a  68040  based  VME  processor  card  and  a  68020  based  VME 
serial  I/O  card. 

The  software  breaks  downs  into  a  number  of  separate,  but  interconnected,  component  parts.  This  break 
down  is  the  same  for  both  subnets,  since  the  NATO  software  is  based  on  the  code  written  for  the  DSCS  subnetwork. 

The  major  software  components  are  the  Client  Handler,  this  component  provides  the  interface  to  the  CSNI 
Intermediate  System  (IS),  it  has  been  designed  to  be  conformant  with  the  SNAC  External  Interface  Specification,  ref. 
[2].  The  Subnet  Protocol,  this  modules  handles  all  the  processing  required  for  transmitting  and  receiving  SnPDUs, 
including  the  generation  of  Acknowledgments  and  Retransmissions.  The  Modem  Device  Driver  provides  the 
software  interface  to  the  modem/terminal  equipment  (this  software  component  runs  on  the  VCOM-24  card). 

2.3  _ Hardware  Implementation 

The  Client  Handler  and  the  Subnet  Protocol  are  executed  on  a  VME  card,  the  Heurikon  HK68V4F 
processor  card.  The  HK68V4F  interfaces  to  the  IS  via  Ethernet.  The  output  from  the  Heurikon  card  is  passed  to  the 
VCOM-24  card,  where  it  is  processed  by  the  Modem  Device  Driver  and  sent  to  the  Modem.  The  VCOM-24  card 
also  provides  the  serial  data  link  to  the  Modem  (the  type  of  interface  was  a  local  issue,  dependent  on 
modem/terminal  hardware  used). 

Figure  5  shows  the  hardware  required  for  each  SHF  SATCOM  subnetwork.  The  Intermediate  System  (IS)  is 
the  Multinet  Controller  (which  includes  the  router). 
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Figure  5.  SHF  SATCOM  Hardware  Configuration 


The  DSCS  subnetwork  uses  the  commercially  available  ComStream  CPIOI  PSK  Burst  Modem.  The  NATO 
subnetwork  utilizes  NATO  SATCOM  modem/terminal  equipment  for  the  GE-UK  and  GE-STC  links,  and 
commercial  IBS/IDR  modems  for  the  NL-STC  link. 

2.4  Test  Results 

The  following  two  subsections  provide  a  summary  of  the  basic  performance  characteristics  of  the  two  SHF 
SATCOM  subnetworks.  The  message  submission  rate  for  all  the  tests  was  one  per  second. 


2.4. 1  Summary  for  DSCS 
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The  DSCS  tests  were  carried  out  with  two  members 
summarizes  the  results  for  the  four  test  NPDU  sizes. 


joined  to  the  subnetwork  (STC  and  UK).  Table  1 


Test  NPDU 

Size 

(bytes) 

Average 

Transmission 

Delay 

(milliseconds) 

Bytes 

Transmitted 

Bytes 

Retransmitted 

Bytes 

Dropped 

100 

889 

2815 

10 

0 

400 

1032 

11345 

145 

0 

800 

1070 

23200 

560 

0 

1400 

1410 

39282 

588 

0 

Table  1.  Summary  of  DSCS  Results 


2.4.2  Summary  for  NATO  IV 

The  NATO  tests  were  carried  out  over  the  GE-UK  Point-to-Point  link.  Table  2  summarizes  the  results  for 
the  four  different  test  NPDU  sizes. 


Test  NPDU 

Size 

(bytes) 

Average 

Transmission 

Delay 

(milliseconds) 

Bytes 

Transmitted 

Bytes 

Retransmitted 

Bytes 

Dropped 

100 

565 

2931 

108 

0 

400 

566 

11711 

411 

0 

800 

644 

23446 

769 

0 

1400 

786 

41038 

938 

0 

Table  2.  Summary  of  NATO  Results 


2.5  Lessons  Learned 

2.5.1  Improve  DSCS  Frame  Structure 

The  DSCS  frame  structure  seems  to  be  inefficient  since  it  never  uses  all  the  slots  in  a  frame.  The  empty  slot 
appears  in  every  frame,  however  it  is  only  ever  used  when  a  PO  wishes  to  join  the  DSCS  subnet.  Since  POs  join  the 
DSCS  subnet  infrequently  it  appears  to  be  inefficient  to  provide  an  empty  slot  in  every  frame. 

The  best  solution  would  be  to  include  an  empty  slot  in  every  ’N'  frames  rather  than  every  frame.  This 
would  improve  the  throughput  offered  by  DSCS,  but  retain  the  same  basic  join  methods.  Joining  would  take  longer, 
but  since  joining  is  a  rare  event  this  should  not  be  overly  inconvenient. 
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2.5.2  DSCS  Token  Passing  Algorithm 

The  token  passing  algorithm  currently  employed  by  DSCS  is  very  simplistic;  the  token  is  always  passed  to 
the  next  PO  in  the  DSCS  subnet.  The  algorithm  needs  to  be  made  sensitive  to  the  traffic  load  present  at  each  DSCS 
SNAC  active  in  the  subnet.  This  would  improve  transfer  times  and  increase  the  efficiency  of  the  link. 

The  token  passing  algorithm  should  be  further  investigated  (i.e.  to  see  which  is  the  best).  Currently  the 
token  is  passed  irrespective  of  how  much  remaining  data  a  SNAC  has  to  transmit. 

2.5.3  Satellite  Emulation 

Testing  of  the  performance  of  the  DSCS/NATO  subnet  protocols  and  modem  interface  software  could  have 
been  more  thorough  had  it  been  possible  to  emulate  the  satellite  link  in  a  controlled  manner.  In  this  way  it  would 
have  been  possible  to  recreate  scenarios  that  caused  problems,  thus  aiding  the  investigation  of  the  problem  and 
determining  of  a  solution. 

2.5.4  Design  of  TDMA  modems 

With  DSCS  it  has  been  noticed  that  power  levels  from  each  site  must  be  balanced  because  the  modem  has  a 
slow  acting  Automatic  Gain  Control  (AGC)  circuit  which  causes  problems  when  the  signal  level  changes,  as  it  may 
from  slot  to  slot  (member  to  member). 

When  implementing  modems  for  TDMA  applications  the  AGC  circuit  must  be  designed  to  be  fast  acting 
because  the  signal  level  may  change  in  each  slot.  If  the  power  level  at  each  site  differs  significantly  (which  could  be 
the  case  if  mobile  equipment  is  used)  it  can  take  a  significant  (compared  to  the  number  of  sync  bits)  amount  of  time 
to  adjust  causing  data  to  be  lost. 


3.0  UHF  SATCOM 

3.1  Protocol  Description 

The  UHF  SATCOM  subnet  is  a  broadcast  network  which  uses  a  reservation  protocol  [5].  The  protocol 
supports  a  maximum  of  64  members  in  the  network.  The  cycle  time  is  variable  because  the  channel  allocation  to 
each  member  is  dependent  on  their  request.  A  Net  Control  Station  (NCS)  arbitrates  the  requests  and  the  determines 
the  allocation  for  each  member.  The  maximum  allocation  a  member  can  receive  per  cycle  is  9000  bytes.  The  raw 
data  rate  over  the  UHF  SATCOM  channel  is  9.6  Kbps.  The  effective  data  rate  of  the  channel  is  about  800  bytes  per 
second. 

The  protocol  is  designed  to  fairly  and  efficiently  use  the  satellite  channel  with  resource  allocation  based  on 
user  demand.  The  protocol  consists  of  a  series  of  net  cycles,  each  of  which  is  initiated  by  a  NCS.  The  net  cycle  is 
composed  of  a  series  of  Transmission  Units  (TUs),  one  from  each  transmitting  net  member.  A  TU  consists  of  certain 
fixed-length  header  fields  plus  zero  or  more  variable-length  messages  containing  either  NPDUs  or  link  control 
information.  The  header  format  is  shown  in  figure  6.  A  reliable  subnet  is  provided  by  having  each  receiving  SNAC 
broadcast  an  acknowledgment  for  each  PDU  indicating  whether  it  was  received  correctly  or  not. 

There  is  one  NCS  per  subnet,  although  other  stations  can  be  capable  of  assuming  the  role  of  NCS  in  the 
event  of  failure  of  the  primary  NCS.  To  initiate  each  net  cycle,  the  NCS  transmits  a  TU  which  contains  a  Sequence 
Order  List  (SOL).  The  SOL  will  contain  a  list  of  stations  which  gives  each  node  a  transmit  opportunity  during  the 
given  net  cycle,  a  list  of  recognized  net  members  which  will  not  transmit  during  this  cycle  (if  any)  and  the  net  cycle 
number  currently  in  effect.  Each  transmitting  station  is  given  a  transmit  position  within  the  net  cycle  and 
transmission  length  assignments  by  the  NCS.  The  assignments  are  based  on  requests  from  the  individual  stations 
during  the  last  net  cycle  and  the  priority  of  those  stations  (only  if  some  stations  are  prioritized  relative  to  other 
stations).  The  lengths  of  the  assignments  are  restricted  by  the  maximum  slot  length  (for  one  station)  and  the 
maximum  cycle  length,  both  of  which  are  set  in  the  NCS  software.  The  NCS  will  reduce  a  station's  transmit 
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opportunities  to  less  than  once  per  cycle,  if  the  station  consistently  indicates  that  it  has  no  data  to  transmit.  The 
station  opportunities  will  not  be  reduced  to  less  than  once  per  four  net  cycles,  so  that  it  will  have  the  chance  to  make 
a  request  if  data  become  available. 

Each  net  member  will  transmit  its  TU  at  the  conclusion  of  its  predecessor's  transmission  (its  predecessor  is 
determined  from  the  SOL).  The  true  length  of  the  predecessor’s  transmission  is  available  from  the  beginning  of  the 
TU  (not  from  the  SOL). 
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Figure  6.  Transmission  Unit  Format 


An  error  in  either  CRC  1  or  CRC  2  upon  receipt  will  cause  the  receiving  SNAC  to  drop  the  entire  TU.  Each 
message  following  the  header  fields  is  made  up  of  the  message  itself  and  an  8-bit  CRC.  The  receiving  SNAC  drops 
any  messages  for  which  the  CRC  indicates  an  error. 

A  transmit  queuing  capability  is  maintained  by  the  SNAC.  The  data  sent  by  the  IS  is  queued  on  a  first- 
in/first-out  (FIFO)  basis  except  for  the  highest  precedence  level  data.  The  data  with  highest  precedence  level  is 
transmitted  ahead  of  other  data. 

Received  data  is  examined  and  routed  to  the  destination  IS.  Any  data  within  the  received  TU  that  is  not 
directed  to  the  local  IS  is  discarded. 

3.2  Software  Implementation 

The  UHF  SNAC  consists  of  one  Computer  Software  Configuration  Item  (CSCI)  and  the  CSCI  is  composed 
of  seven  Computer  Software  Components  (CSC):  SNAC  Manager  (SM)  ,  Net  Control  (NC),  Transmit  Queuing 
(XQ),  Link  Driver  (LD),  Interprocess  Communications  (IC),  Time  Keeping  (TK),  Statistics  Maintenance  (ST).  The 
SM  CSC  is  the  first  CSC  to  start  and  it  subsequently  initializes  the  other  CSCs.  It  also  fields  input  messages  and 
PDUs  from  the  ISs  and  routes  them  to  the  appropriate  CSC.  The  XQ  CSC  maintains  prioritized  FIFO  queues  that 
holds  the  outgoing  PDUs.  It  builds  a  TU  composed  of  PDUs  when  called  upon  by  the  NC  CSC.  The  NC  CSC 
performs  network  control  by  managing  access  to  the  UHF  SATCOM  link.  The  NC  CSC  implements  the  reservation 
protocol.  If  the  SNAC  is  the  Net  Control  Site  (NCS),  the  NC  CSC  performs  the  NCS  functions  of  creating  a  SOL  and 
assigning  time  slots  for  the  other  net  members.  The  ST  CSC  maintains  the  statistics  required  by  the  ISs  and  called 
out  in  the  SNAC  Interface  Document  [3].  The  IC  CSC  established  the  communications  between  the  SNAC  and  ISs. 
The  TK  CSC  maintains  a  record  of  the  SNAC  time  and  initiates  time  driven  functions.  Finally,  the  LD  CSC  provides 
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the  interface  between  the  SNAC  and  the  I/O  controller  on  the  MVME333  serial  I/O  board.  All  the  software  is  written 
in  C  using  the  VxWorks  development  environment. 

3.3  Hardware  Implementation 

The  CSCI  is  executed  on  a  VME  card,  the  Heurikon  HK68V4F  processor  card.  The  HK68V4F  interfaces  to 
the  IS  via  Ethernet.  The  output  from  the  Heurikon  card  is  the  TUs.  This  data  is  sent  to  the  Motorola  I/O  card  which 
provides  the  interface  to  the  WSC-3  radio.  The  I/O  card  output  interface  is  RS232.  The  WSC-3  requires  an  MIL188- 
114  interface.  So  a  RS232  to  MIL188-114  converter  is  used  to  interface  the  I/O  card  to  the  WSC-3  radio.  A  block 
diagram  of  the  hardware  is  shown  in  figure  7. 

The  radios  operate  in  half  duplex  mode.  The  WSC-3  only  has  one  synthesizer  and  therefore  can  not  transmit 
and  receive  at  the  same  time.  It  would  have  been  preferred  to  operate  in  full  duplex.  However,  that  would  have 
required  two  WSC-3  radios  per  node.  The  UHF  SATCOM  subgroup  decided  to  use  half  duplex  because  some  the 
participating  organization  did  not  have  enough  radios  to  operate  full  duplex.  Full  duplex  operation  would  have 
eliminated  part  of  the  guard  band  between  TU  transmissions.  The  guard  band  between  TUs  is  0.58  seconds  and  is 
required  because  of  path  delay  (0.28  seconds)  and  header  delay  (0,30  seconds).  Full  duplex  operation  would  have 
eliminated  path  delay  and  resulted  in  a  guard  band  of  0.30  seconds. 


Figure  7,  UHF  SATCOM  Hardware  Configuration 


3.4 _ Test  Results 

The  data  from  four  tests  runs  is  shown  in  table  3.  The  network  consisted  of  only  two  nodes  of  which  one  is 
the  Net  Control  Station  (NCS).  Four  different  PDU  sizes  were  tested.  There  are  two  point  that  should  be  noted.  (1) 
Even  though  data  were  occasionally  retransmitted,  data  were  never  lost.  (2)  As  the  amount  of  data  increases  per  time 
period,  the  average  delay  also  increases.  This  is  expected  because  the  TUs  are  becoming  larger  since  there  is  more 
data  per  second  to  transmit.  It  is  also  interesting  to  note  that  the  average  delay  of  the  NCS  is  about  half  of  the  delay 
for  a  regular  node.  This  is  also  expected  because  the  NCS  does  not  have  to  wait  a  net  cycle  to  request  channel 
allocation.  The  other  nodes  have  to  request  channel  allocation  in  one  cycle  and  then  receive  their  allocation  in  the 
next  net  cycle. 
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Test  No. 

Node 

Bytes/PDU  per 
sec.  per  node 

Bytes 

Transmitted 

Bytes 

Retransmitted 

Bytes 

Dropped 

Ave.  Delay 
(milliseconds) 

1 

1  (NCS) 

100 

10400 

700 

1973 

2 

100 

12500 

400 

0 

3035 

2 

1  (NCS) 

220 

22220 

5500 

0 

3271 

2 

220 

22220 

7260 

0 

6619 

3 

1  (NCS) 

325 

31525 

2600 

0 

3562 

2 

325 

34775 

2600 

0 

6432 

1  (NCS) 

625 

63750 

0 

0 

11256 

2 

625 

60000 

0 

0 

21695 

Table  3.  Summary  of  UHF  SATCOM  Test  Results 

3.5  Lessons  Learned 

One  of  the  early  design  decision  made  by  the  UHF  SATCOM  subgroup  was  to  use  the  internal  modulator  of 
the  WSC-3  radio  rather  then  an  external  modem.  One  of  the  early  lessons  learned  was  that  the  internal  modulator  is  a 
very  poor  modulator.  The  modulator  required  a  large  period  to  synchronise  which  resulted  in  larger  guard  band.  Also 
the  modulator  was  very  susceptible  to  noise  which  caused  TUs  to  be  lost,  resulting  in  the  SNAC  retransmitting  the 
TU.  It  was  also  discovered  that  the  radio  had  excessive  frequency  draft.  This  was  solved  by  connecting  the  radio  to 
an  external  frequency  standard. 


4.0  CONCLUSIONS  &  RECOMMENDATIONS 

Two  SATCOM  networks  were  successfully  developed  for  CSNI:  SHF  and  UHF.  Both  networks  were 
successfully  tested  over  the  air.  The  DSCS  and  NATO  SHF  SATCOM  subnetworks  provide  the  CSNI  program  with 
two  high  capacity  data  links  (a  data  rate,  excluding  protocol  overheads  of  41.5  and  53.6  Kbps  respectively).  The  two 
SHF  subnetworks  are  reliable  (during  the  basic  performance  tests,  see  2.4,  no  data  was  lost). 

If  the  two  SHF  SATCOM  subnetworks  are  to  be  used  in  a  true  military  environment  then  further 
development  work  is  required  on  both  DSCS  and  NATO  subnets.  There  are  several  possible  enhancements  that 
could  be  made  to  the  SHF  SATCOM  subnetworks  to  improve  the  throughput,  the  joiningAeaving  processes  (DSCS 
only)  and  the  token  passing  algorithm  (DSCS  only).  Some  of  these  enhancements  were  detailed  in  2.5. 

The  UHF  SATCOM  subnetwork  provides  CSNI  with  a  low  data  rate  SATCOM  subnetwork.  Since  most 
military  channels  are  low  data  channels,  the  UHF  SATCOM  subnetwork  provided  CSNI  with  a  channel  to  test  OSI 
protocols  over  low  data  rate  SATCOM  links. 

The  UHF  SATCOM  subnetwork  proved  to  be  a  reliable  network.  However,  further  improvements  can  be 
made  to  the  subnetwork  design,  particularly  to  the  hardware.  Operating  full  duplex  would  decrease  part  of  the  delay 
in  the  network  and  decrease  the  net  cycle  time.  The  use  of  a  better  modem  would  increase  the  reliability  of  the 
network  and  decrease  retransmissions.  This  would  also  decrease  delay. 
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